It's the keyboard layout.

[Saber]

I'm not saying that US-QWERTY makes more sense than German QWERTZ or French AZERTY. It doesn't. None of the frequently used keyboard layouts really make sense. They just are what they are.

But I do think that it's better to try to follow just one of them (and I would argue it should be US-QWERTY), and follow it as closely as possible (within the constraints of having limited keys etc). I think it's a bad idea to do the letters like in the US, the shifted comma and period like in Germany and the shifted number row like something else again.

By follow I think you mean approximate. I remember how adamant you were for an uncentered "left-centric" lettered keyboard. P+2 and L+3. How it was "the way". Then it was Greek letters instead of ABXY. Then the single key spacebar protesting. Back to Greek again. None of those came to be. So in practice the act of respecting a convention, any convention, needs to be diregarded when developing a layout for the Pyra. Otherwise we end up nowhere fast by imposing these limits that no one seems to know why are being followed in the first place, only that others have before us and vaguely we must as well, for a handheld that isn't a desktop.    

 

[Neelix]

So in practice the act of respecting a convention, any convention, needs to be diregarded when developing a layout for the Pyra. Otherwise we end up nowhere fast by imposing these limits that no one seems to know why are being followed in the first place, only that others have before us and vaguely we must as well, for a handheld that isn't a desktop.    

Well,  there's no need to throw out the baby with the bathwater.   Just because not all conventions are going to be appropriate for our purposes doesn't mean they should all go out the window, otherwise we may as well discard the QWERTY layout altogether and arrange the keys alphabetically. The QWERTY layout was chosen because it will be the most familiar layout to the most number of people, so maintaining as much of that familiarity as possible would be a good idea. 

- Neelix

 

[rygD]

On the nature of four characters per key, I took the liberty of gimping this together

Spoiler

Spoiler

All I did was move the F* keys over, and copy them into the upper right corner. As you can see they fit fairly well, quite visible, no squinting required. It's especially cromulent at the F5-F7 keys which are basically dead center of the image; I didn't shift those on the Y axis at all, just moved them directly to the left and a copy in the top right corner.

The F# markings are difficult for me to see on the Pandora.  I am not saying this won't work, since the biggest problem is that the top row falls in a shadow for me frequently, so a backlit keyboard, and that row being moved away from the hinge will make additional markings more visible.  I still have doubts about the amount of printable space on the keycaps, which I think are smaller than the number row on the Pandora.

 

[TrashyMG]

I still have doubts about the amount of printable space on the keycaps, which I think are smaller than the number row on the Pandora.

The numeral keys on the Pandora is about the size of what the regular keys will be on the Pyra, what Wizardstan shown on the picture is a good approximation.

 

[comradekingu]

Most people use qwerty, so if we use that, then we cover most people. In _not_ putting symbols all over the typewriter area, its possible to cut out a key and place it somewhere else. Not saying this is a killer feature, but its better than not having that option as easy as possible.

It cant be US layout fully, nor does US layout cover international typing concerning the amount of keys we have. One reason why US layout isnt ideal, nor is US numberlayout is if you consider dead-keys.

US layout is just made for 104keys, and US layout is lazier than the ones who need to use the full layout for letters. Actually its made for way less than that, and then things have been added willy-nilly later on. Also one reason why it doesnt make sense.

Needless to say, the strictest adherance to US layout nobody wanted, so its a balance-act.

Many things are possible, but within standards of expectation and implementation, it is possible to arrive at other balanced methodologies here.

Its not just germany that does , ; and . : btw.  The use-cases can make sense and be implemented within reason. Like coding for example.

Saber has been pretty adament that no questions be raised, and certainly not answered, concerning his layouts. And he explains only one change at the time, everything else you have to guess.

Designing based on things that cant be questioned and rationally discussed in a general conversation are bound to have shortfalls.

You may be 100% correct about what you think ED wants, but i can guarantee you havent considered all the changes to the use-cases you change by doing everything so differently.

One quick way to end up nowhere is to call people out over proposing changes. That is quite bad-mannered.

Wb may have been supporting things in the wrong way, who knows, point us to it.

Supporting things with choice-of-words rather than arguments is strange.

You are calling a fuller layout " uncentered "left-centric" "

I dont know why, but both are clearly biased. If the placement of A isnt centered around where the keyboard starts for all people, I guess you mean the english keyboard only. Over half the votes suggest a preference for a fuller layout, which is "full" in the same sense its otherwise "empty" on the right hand side.

Putting a reduced english layout closer to the left only to have the modifiers and punctuation all on the right, is hardly left-centricm, considering the weight is already  left to begin with. As has been pointed out and researched.

You dont appear to have read 1984, beause the term is double-speak, not double-talk.

I find the discussions very informative and helpful in learning design and improving my layout. Things like this are helpful.

Non-discussions and unsubstianted personal attacks, not so much.

In case you meant ambiguity.

Spoiler

People to a large extent dont even know how to use regular AltGr. If you want to change something because of an already changed convention in the number of keys, change that. Design around it by only requiring shift, which people do understand.

 

Colour-codes also fail. And they look ugly.

 

Inability to press shift+Fkeys  takes away web and text functionality in KDE and GNOME, probably other DEs too.

 

Shift+AltGr to do a combination of what  real keys, shift and AltGr does fails wholesale.

All of the above isnt neccesary. So it begs the question, why? What is the benefit? If you reduce down to pandora amount of keys, i see it. Pyra i dont, because ive seen it done differently.

Compromise made due to lack of key real-estate isnt good. As soon as its not required, it should be done away with.

 

For the people that use AltGr, I can speak for myself.

Why should someone come and forcibly decide for me, where the AltGr letter symbols are, and take away my AltGr?

Its just visual noise that nobody has a full use of, so it gets on everyones goat. And if you have full use of it, its because you have been stripped of both full layout, french type accentuation on number row, compose character, and regular AltGr functionality.

 

Yes there can be a default, why does it have to be visual? AltGr symbols on letters never are. Regular symbols belong on the number-row. And on P+ and L+ if you have reduced layout.

2 letters per key looks like a toy keyboard. And you arent getting the benefit of that anyhow.

 

You are jumping ahead and implying it is a case of difference in use. Im saying its a case of difference of purchase.

 

Selling someone a keyboard works by selling a keyboard. No keyboard that strayed away from this has ever been accepted by the general mass. We are still to a great extent, using 1984 type keyboards.

I wasnt born then, but i know computing was a whole lot different. Things didnt change, because people dont buy irregular keyboards.

 

And with software changing, functionality was piled onto already existing buttons. Change something, and break something.

 

So if we agree conventions are better for compatibility and novices, what benefit does your layout provide pros which justifies raising the treshold on who can use it/will buy it?

 

You can disagree the pyrakeyboard isnt one because of a lack of keys, but it doesnt make the argument more sound if it doesnt work like one either.

 

When was ever mobile-keyboard better than regular keyboard?

 

On a related note, are there any features meant for two-thumb typing?

 

Ask people who have never used a pandora to explain to you how your keyboard works. Say only the words yes and no. As if what would happen if they tried to do it. I _guarantee_ you will be suprised.

Okay. All that is double talk and gibberish. Like watching a dog chase it's tail. Nobody is forcing you to accept this keyboard. If you want a different layout then please work on yours some more and cut the nonsense. People have far greater comprehension skills then you give them credit. The labels color will match the modifier.

 

Honestly, I don't care if AltGr works differently on other keyboards. It absolutely does behave differently when pushed on every regional keyboard out there depending on where you plant your feet.

 

ED wants to use AltGr as our modifier. If he goes with another label name then that's fine. Sym or Char maybe or even Fn(on the surface). It'll have a mapping customized to our needs given the number of keys we have to work with, but it will still be an AltGr, our AltGr, a modifier that brings up symbols and characters when pressed in combination with a letter, with a keymap exclusive to the Pyra. Must I repeat this over and over?   B)

(I put that in bold)

So since AltGr is different between regions, does mean it can be entirelly arbitrary to AltGr? I dont see a problem with respecting each regions expected behavior. Or someones will to change it easily. Unless you mean it as an excuse to put symbols all over the letters to hamper this functionality.

Yes the pandora keyboard is different, but you seem to use that as a stopgap argument as 'anything goes'

 

[codifies]

I still have doubts about the amount of printable space on the keycaps, which I think are smaller than the number row on the Pandora.

The numeral keys on the Pandora is about the size of what the regular keys will be on the Pyra, what Wizardstan shown on the picture is a good approximation.

jeeze *that* small and people want 4 symbols per key....

 

[rygD]

I still have doubts about the amount of printable space on the keycaps, which I think are smaller than the number row on the Pandora.

The numeral keys on the Pandora is about the size of what the regular keys will be on the Pyra, what Wizardstan shown on the picture is a good approximation.

Right, but the key cap will not be the size of the full top of the key.  Unless the printing goes all the way to the edge of the key cap I think the area avaialable for printing will be less than it was on the number row on the Pandora.  I may be wrong, I have never seen the Pyra keyboard samples in person.  I just think it might be beneficial to keep that in mind until we can see a Pyra key cap right next to a Pandora number key.  

Also, a lot of tiny markings will be harder for some people to see than less that are larger.

 

[comradekingu]

It is said to be 3x7mm.  With those dimensions 4 prints will be smaller than 3 can be. And 3 uses the space more efficently than 2.

To utilize the space and reduce clutter 3 and 1, where 1 is bigger than the individual 3, is ideal.

Not so for readability though, since 3 is even so less than 1. In this case the consideration falls in favour of 2.

To bring that design-win home, something needs to be done about "ctrl/select"

 

[codifies]

1.5mm X 3.5mm is damn small !

at least with just 2 symbols you can "overlap" the virtual square of a character without the actual symbols touching as there is usually a bit of spare space in the corners...

(probably didn't explain that too well?)

 

[Grench]

So, I was thinking, and that's not always a good thing.

A 'Normal' US standard keyboard (excluding number pad) breaks down by top level key type as:

26 letter keys qwertyuiopasdfghjklzxcvbnm

10 number keys 1234567890

12 function keys F1-F12

11 symbol keys `,./;'[]\-=

9 modifier keys capslock, Lshift, Lalt, Lctrl, Rshift, Ralt, Rctrl

5 main 'special' keys Tab, Space, Enter, Backspace, Escape

10 navigational/edit keys up, down, left, right, Insert, Delete, Home, End, PgUp, PgDn

3 system control keys PrtSc, ScrLk, Pause

That is 86 usable keys on a 'normal' US standard keyboard.  Add 2 for the mouse = 88.

The Pyra has:

4 shoulder buttons

4 'keys' in the D pad

7 keys in the center 'T'

2 'keys' by pressing the nubs

6 keys in the right game pad

45 in the 'main' section

That is 68 usable keys on a 'Pyra' (including the 2 on the nubs).

So, the Pyra starts with a 20 key deficit.  

Making an assumption here, but I believe we want to make sure that the entire US keyboard set AND includes provisions for a few non-English languages are taken into account.  The method of using Fn+Shift+key has opened up enough potential places to map things to that this IS possible.

However, we're chasing each other in circles because no matter how it's arranged, something must be compromised to do it.

I see this as a choice of a few trade-offs.

If numbers are going to live on the top level of the top row, symbol keys are going to be forced to a Fn+key and Fn+shift+key level.

We can have one or the other - numbers top level OR symbols (punctuation, etc.).

The keyboards I generated with the numbers on the Fn level caused immediate outcry.  But, which is worse?  Having numbers on the Fn level OR having symbols on the Fn level?

If we can accept that the symbol keys should take precedence over the numbers keys, something very interesting can happen.

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

And that right Alt key?  It should be able to be a 'real' AltGr, if the user selects a US International keyboard type.

To avoid the 'clutter', I did not put the AltGr symbols on the above layout.  It would work out like this, if the AltGr symbols were mapped to the US layout's base symbols:

http://en.wikipedia.org/wiki/AltGr_key#US-International

Note, this is a first attempt at yet another completely different layout.  It will likely require some refining and adjusting.  It is posted here as an idea for thought and discussion.  It is a prop for the question of, "What if we gave symbols precedence over the number row."

I think it shows promise.  What are your thoughts?

 

[rygD]

It is said to be 3x7mm. 

I don't have anything better than a cheap ruler with which to measure and it looks to be about 9mm wide by about 5.5 mm high for a "small" Pandora key.  This was overall key dimensions, not just the (domed) top.  Markings on Pyra keys may need to be smaller than on the Pandora to fit the same things on the key caps.

 

[codifies]

Thats a reasonably well thought out analysis - I don't know how it could be managed exactly (to be honest) but I'd like something like this but with number keys as first class citizens...

I wonder if it would be worth analyzing German, French etc for frequency of diacritics - it would need a native speaker to select decent modern language text's.

I could write scripts to do the analysis if needed but a decent search feature should tell you the number of any particular character - if its a long list I could make a set of totals from a string of diacritic characters

Speaking of diacritics I'd be very concerned that all that verbiage on the diacritic key wouldn't fit on such small keys.

 

[Saber]

So in practice the act of respecting a convention, any convention, needs to be diregarded when developing a layout for the Pyra. Otherwise we end up nowhere fast by imposing these limits that no one seems to know why are being followed in the first place, only that others have before us and vaguely we must as well, for a handheld that isn't a desktop.    

Well,  there's no need to throw out the baby with the bathwater.   Just because not all conventions are going to be appropriate for our purposes doesn't mean they should all go out the window, otherwise we may as well discard the QWERTY layout altogether and arrange the keys alphabetically. The QWERTY layout was chosen because it will be the most familiar layout to the most number of people, so maintaining as much of that familiarity as possible would be a good idea. 

- Neelix

Qwerty definitely yes, but all the rest needs to go through a fine-toothed comb, multiple times if need be and not just strictly adhered to only because a full grown PC has it customarily another way that won't work so well in our case. 

 

[Saber]

If we can accept that the symbol keys should take precedence over the numbers keys, something very interesting can happen.

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

Note, this is a first attempt at yet another completely different layout.  It will likely require some refining and adjusting.  It is posted here as an idea for thought and discussion.  It is a prop for the question of, "What if we gave symbols precedence over the number row."

I think it shows promise.  What are your thoughts?

Number keys must be primary. While the symbols are paramount, the Pyra on the other hand isn't a coder's only device. Everybody needs numbers but not everybody needs say brackets. 

 

[codifies]

...not everybody needs say brackets. 

Heresy! The very idea!   ...  if brackets have to take a bit of a back seat for numbers then fair enough - but they need to be somewhere on there!

 

[Saber]

...not everybody needs say brackets. 

Heresy! The very idea!   ...  if brackets have to take a bit of a back seat for numbers then fair enough - but they need to be somewhere on there!

{ } [ ] on the shoulder buttons. 

 

[codifies]

...don't even go there... Someone will agree and make their darling pet layout and then its 20+ posts later...

 

[Neelix]

If we can accept that the symbol keys should take precedence over the numbers keys, something very interesting can happen.

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

...

I think it shows promise.  What are your thoughts?

You're right...   that's an interesting concept...   I really like that bottom row of punctuation keys... but...

I've already got 2 devices that have the number keys as secondary symbols on the qwerty row.  Both are a real pain in the arse if I want to enter a number or especially if I have to alternate numbers and letters. (like in a password or a MAC address)   That's kind of left me burned on the concept, so at this point I'm not willing to give up the dedicated number row, and I think to convince me otherwise would require a working prototype, which isn't going to happen.  *shrugs*

- Neelix

 

[WizardStan]

If we can accept that the symbol keys should take precedence over the numbers keys, something very interesting can happen.

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

Yet another really clever idea. Again, it feels wrong, and there are some obvious objective measures that say numbers are more important than brackets, but it does bring some good benefits. Do the benefits outweigh the cost of a secondary number row? Gonna have to ponder that.
On a different note, is there a good reason you've got the shoulder Fn and Shift being lock-able? Seems to me it causes more problems than it solves but I may be misunderstanding.

 

[rygD]

Note, this is a first attempt at yet another completely different layout.  It will likely require some refining and adjusting.  It is posted here as an idea for thought and discussion.  It is a prop for the question of, "What if we gave symbols precedence over the number row."

I think it shows promise.  What are your thoughts?

I want to give brief feedback.  I probably have not yet any replies to this post.  The first thing I dislike, but that should not be a problem, is having "Pyra" (is it Super, Menu or something else?) on the spacebar.  I think it might be best to skip it if it won't have the logo and be in an attention grabbing and useful (in the Pandora sense) place. Tab seems annoying to use (two hands, or shoulder button, or locked to use Tab?).  Any key!!!

Are Fn and Shift sticky?  I am fine with those, but some seem to be opposed to sticky keys.  Being able to lock the numbers should be useful in many cases.  It might be better for some to go with a num pad layout, however that is probably "too different" without a number row.

There are good aand bad in the F1-F12 row.  Some will like that it is all on one row.  You can do shift+Fwhatever as far as I can tell.  It requires full F# markings on those keys, and are not associated with the numbers, but should be easy to learn pretty quick (4th key in second row is F4, same for number row).

The top row, above the nubs, has what I think ED wants there, but some are not primary.  I wish Esc was closer to the keyboard, however I can tolerate it there.  Does display brightness go up and down (and if so how?...I can guess the answer), or does it just keep stepping up until maximum brightness, and the next step is off/minimum?  Good choice on keeping 3G/4G and bluetooth as secondary functions.  With possible voice users these may become more important.  I can imagine problems from having Esc on the keyboard light button, but no clue if they would really happen more than once per user.

Is Delete on the c button?  Could the keys between the nubs cause problems in games/emus if used for start, select and, uh, pause, which in many games I play is done by pressing start (I understand it is the pause key, not in addition to start and select as gaming buttons, but it looks like it is).

I am interested in seeing what people who need more than just English have to say, and if it works for QEMU/DOSBox (I didn't compare it to a normal keyboard).

I hope my comments are useful.