Pyra keyboard layout - requirement analysis

[Grench]

In my opinion, it should follow as closely as follows the standard QWERTY keyboard layout:

Spoiler

Spoiler

in terms of key positioning, but of course it cannot have all those keys. If a key exists, it's shift value should be the same as normally, e.g. the symbols on the number row.

If a key does not exist, it should be an Fn key in a position that is as near as possible to the right position.

The only reason not to follow this approach is to make it look more like the Pandora layout. E.g. it's OK to have ,.<> to the left of Z like on the Pandora.

The gaming controls have to be backwards compatible with the Pandora: the dpad should still be arrow keys, ABXY should still be home/end/pgdn/pgup, L1 has to be RSHIFT and R1 has to be RCTRL. Extra shoulder buttons should preferably be modifier keys (e.g. alt); extra gaming buttons should preferably be mapped to one of insert/delete/backspace.

All the (primary) keys that have dedicated keys on the Pandora should also have dedicated keys on the Pyra.

A dedicated TAB key should be added. A dedicated Delete key would be nice.

Some requirements that I personally don't care about, but ED has said on IRC that he cares about these:

- The keys should not be less wide than on the Pandora. They can become more rectangular though (less height) to fit a fourth row under the gaming controls.

- Standard German keyboard keys should be somewhere (in particular Ä Ö Ü ß, maybe also € µ ° §), as Fn keys

- Two shift buttons on the keyboard itself, for people who don't use the shoulder button as shift

- The total width of the device cannot increase

That is not a 'standard QWERTY keyboard'. It is an English/Eurpoean ISO bastardization of a 'ANSI standard QWERTY keyboard'. What possessed some British guy to make a keyboard with an enter key the size of a fist?

This is how a proper QWERTY keyboard is laid out:

http://en.wikipedia.org/wiki/File:ANSI_Keyboard_Layout_Diagram_with_Form_Factor.svg

And yes, I realize that is a US standard not an international one.

QWERTY was an American invention: http://en.wikipedia.org/wiki/Sholes_and_Glidden_typewriter.

The international version of a proper QWERTY keyboard: http://en.wikipedia.org/wiki/File:KB_US-International.svg

An aside... Why can't we post links to .svg formatted image files?

 

[_wb_]

Yes, of course we don't want the huge enter button, what I meant was indeed this:

The 80% version. Not sure if we need print screen / scroll lock / pause though, I think we can safely ignore those.

 

[Mr_Loon]

What possessed some British guy to make a keyboard with an enter key the size of a fist?

To make it easy to press as it is a commonly used key, see space bar for reference

IMHO In terms of requirements one of the first things that should be considered is the number of keys, if you look at this keyboard poll you can see that a large majority of potential customers would like to see at least 5 rows of keys (1 row of numbers + 4 other rows) it would make sense to me to meet the desires of your potential customers where possible.

From a personal perspective I'd rather see 1 row of numbers + 3 other rows thus allowing the individual keys to be a larger size, however I'm in an obvious minority with this view. What would be pretty ridiculous in my view would be to choose the worst of both worlds where the top row of keys would be for functions like wireless on off etc and then having 4 additional rows for 'normal keyboard' keys thus failing to make the keys larger & failing to meet the desires of the customer base. I'm hoping the prototype layout seen so far is nothing more than a prototype.

The hardware keyboard is the one thing that will make the Pyra stand out from the competition so it makes sense to me to make it a high priority to give the customers what they want in this area.

 

[_wb_]

The hardware keyboard is the one thing that will make the Pyra stand out from the competition so it makes sense to me to make it a high priority to give the customers what they want in this area.

Sure, but different people want different things. There is no such thing as "what the customers want". Some want to have big keys, some want to have lots of keys. Some want to do thumb typing, some want to try touch typing. Some want the device to become smaller, others don't mind it getting larger. Some want QWERTY, others want DVORAK or QWERTZ or AZERTY or whatever. Some want 3 rows, some want 4 rows, some want 5 or 6 rows. And so on.

So we need some kind of compromise in order to make it as good as possible to as many people as possible. This thread is meant to the define the constraint space in which we're working.

 

[bzar]

...some want user-mappable buttons for unspecified personal needs

 

[Mr_Loon]

Sure, but different people want different things. There is no such thing as "what the customers want". Some want to have big keys, some want to have lots of keys. Some want to do thumb typing, some want to try touch typing. Some want the device to become smaller, others don't mind it getting larger. Some want QWERTY, others want DVORAK or QWERTZ or AZERTY or whatever. Some want 3 rows, some want 4 rows, some want 5 or 6 rows. And so on.

This is true, and it is fully appreciated there is no perfect layout, but the results in the poll make it pretty obvious that a significant majority of people want more than 4 rows of keys. It makes sense to me to listen to their desires.

 

[WizardStan]

Often times what a person thinks they want and what they'd actually be happiest with are not the same thing.

Even more often what a person thinks they want and what is actually physically possible are not the same thing.

Don't take a poll and say "this is how it has to be, that's how the majority voted" because the majority doesn't always know what's going on (see US politics )

 

[TrashyMG]

Not sure if we need print screen / scroll lock / pause though

I can see some of these being handy in some cases of old computer emulation. I surly wouldn't make them dedicated buttons.

 

[Granitehead]

I think this thread needs a more systematical approach, that's what I meant when I suggested a requirement analysis earlier.
We need to keep our requirements and the deducted practical decisions separate.
I ordered the list in the first post and tried updating it with as much information as possible from the posts in this thread.
I made it numbered so people can refer to it while discussing (please do so).
When there is agreement to change something do so, when several parallel discussions let something go under then you can also add the different opinions as subpoints in the list.
To change the list quote the last post containing it, copy the list from the quote to your own post an delete the quote. That way you keep all the formatting nicely.

• hardware
  must be possible to find the keys by touch
  surface form: flat? rounded?
• surface height: lower than now? certainly not higher?
• surface coating: must not stick, fingers should glide over it as easily as possible
• minimum force needed to trigger key: need to be possible to slide finger over key without triggering it

[*]must not force Pyra's dimensions to exceed 1-2mm beyond the Pandora's
[*]must be easy to press

• keyboard:
  1. size:
     width: shouldn't be less than on the Pandora (ED) 
  2. height: can be lowered (ED)
• room between keys: could be lowered I guess, but only technically possible if the plastic ribs between the keys aren't necessary anymore
• maximum force needed to trigger key: shouldn't be too much, of course
• maximum way/travel needed to trigger key: should be low, say 0.3mm, max 0.5mm
  
• gaming buttons: I think they are fine on the Pandora

[*]must not get into the way when gaming

• <practical consequences>

[*]must: resistant to foreign matter (pocket lint) from getting into/between the keys: not possible with the Pandora, could be a problem with mechanical keyboards
[*]must allow for both handheld thumbtyping and desktop finger typing
[*]must have easy to read labels:

• colors:
  must: high enough contrast -> easy to read

[*]should (?) backlighting

• must: variable intensity (I think that's pretty much a free feature when you have backlighting at all)
• could: variable color

[*]possible to map to (generally as many as possible):

• must: qwerty/qwertz/azerty (those are basically the same, so we can group them together)
• must: dvorak
• could: colemak
• could: non latin (Russian, Japanese, etc.) (clarify! what's needed for this?)

[*]gaming controls:

• must: 4 action buttons, dpad, 2 shoulder buttons, 2 nubs
• should: 2 additional shoulder buttons, buttons between nubs
• could: x additional actions buttons

[*]cost: well, this should maybe be a poll. In my opinion it could cost a lot more than CHF9.27 (CHF9.27 (CHF9.27 (CHF9.27 (CHF9.27 ($10))))) if it's also considerably better.

[*]software (default key bindings)

• Should be similar to Pandora's
• Should be similar to US international qwerty
• Which keys need to be there?
  must: all keys and special characters found on a normal US keyboard layout (0-9,a-z, A-Z, ~!@#$%*()-_=+[{]}\|;:'",<.>/?, F1-F12, ESC, Tab, Capslock, shift, ctrl, alt, backspace, enter, insert, delete, home, end, pageup and pagedown.
• should: German characters: äöüß (ED)
• could: support for alternative keycodes for left/right hand modifiers and regular and keypad keys (clarify!)
• should: two shift keys on main keyboard (ED)

[*]what to map to the gaming controls
[*]must be usable using non-sticky modifiers in both of the handheld/desktop modes of typing.
[*]must not prevent valid regular keyboard combinations from being input (e.g. shift-backspace on the Pandora)
[*]must allow mouse motion
[*]must allow left/mouse button clicks
[*]should allow middle mouse button clicks (emulation through left mouse + right mouse is acceptable)
[*]could allow mouse scrolling
[*]should not break the correlation between a key and its shifted value (e.g. ; and : ) on the US international layout.
[*]could: W-LAN, Bluetooth, etc.

 

[levi]

I don't see what point 9.3 [as was] adds to these requirements. It's a badly specified requirement, and I think is captured by trying to implement as many of the requirements as possible anyway.

I tried removing it and adding some of the other requirements listed already in this thread, but at some point I broke the list formatting and couldn't, after numerous retries, get it to parse properly again.  IMO this forum software is not the best medium for encoding such complex lists - the wiki would be better, but there is the danger of things getting lost on the wiki.  Not sure what's best.

After your update: ta!

 

[Granitehead]

I agree that a wiki would actually better fit this kind of work, but as it happens most discussing goes on in the forum. Don't know either, if we want to have a forum thread and a wiki page I guess that might be good too.

1.9.3: I guess that's true. I justed wanted to emphasize it more with this. I'm going to edit my previous post.

 

[traylorpark]

Oddly for me, I care much less about what the key board layout is and way more about what the feel is like and how does it feel physically when I push those keys.


I know that the tall action on the existing Pandora keyboard throws off some people when they try it for the first time.

 

[God Ginrai]

I know that the tall action on the existing Pandora keyboard throws off some people when they try it for the first time.

Tall?

-God Ginrai

 

[traylorpark]

Yup

 

[God Ginrai]

Are you talking about the travel distance of the press?

-God Ginrai

 

[Granitehead]

I think he does.

Edit:

After your update: ta!

Another downside to using the forum - maybe I should have copied it to a new post after all.

 

[Caine]

We could start by grouping the items of that long list by the three sub-issues you named. But I'm going to bed now, plan to think a bit more about it tomorrow.

Indeed. Thank you for doing this.

could be mappable to non latin characters layouts (e.g. Russian, Japanese, Hebrew, ...)

I don't know why you would need that. I can perfectly input Japanese with the current Pandora keyboard. Is that comment coming from Ignorance?

Ignorance? Sounds a bit harsh. Personally I don't give a damn about non-standard US layout and I am perfectly fine with completely ignoring the Japenese layout. So perhaps Japanese layout usage is uncommon, that was not the main point. There are many non-english users which will want to use a default non-US qwerty keyboard layout mapping. I consider this to be mostly an issue of key placement not of labelling. I suspect most will agree that a US or US/international labelled keymat should be the default.
Let me give an example, the homerow of a dvorak keyboard layout is: AOEUIDHTNS- while qwerty uses: ASDFGHJKL:"

I don't think we will be able to fit a full regular keyboard layout and as such we should expect some keys to move. I would rate a keyboard layout which has room for ten keys on the homerow better than one which has but nine (Pandora 1), because then a DVORAK layout can be (software-)mapped to it without having to move the S.

We should strive to not move non-punctuation characters around too much, within limits of reasonability.

Another feedback: your list is flawed. You should not mix "Must / Could / Should" and call it requirements. Only "Must" is requirement, "could" is in the "nice to have" category, wording-wise. As for "should", I don't really understand how it is different from "must" - care to explain ?

As some have indicated, it is prioritization. Having requirements clear allows us to objectively rate suggested keyboard layouts and compare them on rational merits. A keyboard which doesn't satisfy the "musts" is not acceptable. But a layout which satisfies the "musts" and many "shoulds" is a better layout than one which does not.

Surely you mean qwerty and not qwertz?

 The qwertz-layout is a commonly used layout in Germany and some other countries.

Besides, if the keys are in single-part mat, I don't see how you could make this remappable. 

You shouldn't put "must" when you don't know the technical constraints or the supply constraints related to it.

This is about software remappability, not changing the labels.

Probably you meant R1 instead of L2 in the first line.

Whoops, corrected. Thank you.

I don't understand why you don't put a "MUST" for everything that's already in the current pandora, i.e.

Because I want the Pyra keyboard to be equal or better than that of the Pandora.
The list in the initial post it my personal list, observing that you have a fairly clear idea of how I will rate various layouts. The specifics of must/should/etc... are not final and merely a starting point for discussion.

could: support for alternative keycodes for left/right hand modifiers and regular and keypad keys (clarify!)

What I mean with this is that a regular keyboard has some keys doubled (shift, ctrl, alt, /, *, -, +, enter, insert, delete, home, end, pageup, pagedown, left, right, up, down). While these keys are logically the same, the computer can distinguish between them by sending diffent key-codes for each.
We already see many layouts using RCtrl, RAlt for shoulder buttons and LCtrl, LAlt for the regular buttons. This requirement specifies such functionality to be a nice to have. Personally, I think having different codes for the modifiers is more important than for the non-modifiers keys, but if a num-lock were to be included somewhere, then I think it should switch between which version of said key is pressed such that different actions can be bound to it.

An example of why this is useful. On my desktop machine I have LAlt configured as my heavily used Meta key for emacs whereas RAlt is the modifier key of my tiling window manager, which I use to switch virtual desktops and move windows around from one to another.

ome requirements that I personally don't care about, but ED has said on IRC that he cares about these:

- The keys should not be less wide than on the Pandora. They can become more rectangular though (less height) to fit a fourth row under the gaming controls.

- Standard German keyboard keys should be somewhere (in particular Ä Ö Ü ß, maybe also € µ ° §), as Fn keys

- Two shift buttons on the keyboard itself, for people who don't use the shoulder button as shift

- The total width of the device cannot increase

And with this list the majority of the existing keyboard layout designs have been wiped off the table. Especially the key and device width.

 

[levi]

Okay, had a bit more success maintaining the layout this time (tip, stick to BB notation and fix the angle brackets at the end). I've formalised the language, tried to group topics together a bit more and included my requirement.


I still have to fit in Caine's clarifications. But this'll do for a start.

• hardwarekeyboard:MUST: is possible to find the keys by touchsurface form: flat? rounded? concave?
• surface height: no higher than on current Pandora
• surface coating: must not stick, fingers must glide over it as easily as possible
• MUST: allows for both handheld thumbtyping and desktop finger typing
• minimum force needed to trigger key: is possible to slide finger over key without triggering it
• maximum force needed to trigger key: isn't too much, of course (clarify )
• maximum way/travel needed to trigger key: is low, say 0.3mm, max 0.5mm

[*]MUST: is easy to press
[*]MUST NOT: forces Pyra's dimensions to exceed 1-2mm beyond the Pandora's
[*]size:

• width: SHOULD: is as wide if not wider than the Pandora (ED)
• height: MUST: is no taller than the Pandora (ED)

[*]room between keys: could be lowered I guess, but only technically possible if the plastic ribs between the keys aren't necessary anymore
[*]MUST NOT: keyboard gets into the way when gaming

• <practical considerations>

[*]MUST: is resistant to foreign matter (pocket lint) from getting into/between the keys: not possible with the Pandora, could be a problem with mechanical keyboards
[*]MUST: has easy to read labels:

• colors:
• MUST: high enough contrast -> easy to read

[*]SHOULD (?): backlighting

• MUST: variable intensity (PWM?) (Levi)
• COULD: variable color

[*]is possible to map to (generally as many as possible):

• MUST: qwerty/qwertz/azerty (those are basically the same, so we can group them together)
• MUST: dvorak
• COULD: colemak
• COULD: non latin (Russian, Japanese, etc.) (clarify! what's needed for this?)

[*]gaming controls:

• NOTE: I think they are fine on the Pandora (T4b)
• MUST: 4 action buttons, dpad, 2 shoulder buttons, 2 nubs
• SHOULD: 2 additional shoulder buttons, buttons between nubs
• COULD: x additional action buttons

[*]cost: well, this should maybe be a poll. In my opinion it could cost a lot more than CHF9.27 ($10) if it's also considerably better.
[*]software (default key bindings)

• SHOULD: is similar to Pandora's
• SHOULD: is similar to US international qwerty
• Which keys need to be there?MUST: all keys and special characters found on a normal US keyboard layout (0-9,a-z, A-Z, ~!@#$%*()-_=+[{]}\|;:'",<.>/?, F1-F12, ESC, Tab, Capslock, shift, ctrl, alt, backspace, enter, insert, delete, home, end, pageup and pagedown.
• SHOULD: Characters commonly needed for shell usage ( Tab,;,",`,{},[],$,| ) are accessible using only one thumb (not counting sticky Fn) in combination with a modifier from the shoulder buttons. (Levi)
• SHOULD: German characters: äöüß (ED)
• COULD: support for alternative keycodes for left/right hand modifiers and regular and keypad keys (clarify!)
• SHOULD: two shift keys on main keyboard (ED)

[*]what to map to the gaming controls?
[*]MUST: is usable using non-sticky modifiers in both of the handheld/desktop modes of typing. (clarify!)
[*]MUST NOT: prevents valid regular keyboard combinations from being input (e.g. shift-backspace on the Pandora)
[*]Mouse emulation:

• MUST: allows mouse motion
• MUST: allows left/right mouse button clicks
• SHOULD: allows middle mouse button clicks (emulation through left mouse + right mouse is acceptable)
• COULD: allow mouse scrolling

[*]SHOULD NOT: breaks the correlation between a key and its shifted value (e.g. ; and : ) on the US international layout.
[*]COULD: W-LAN, Bluetooth, etc.

 

[Caine]

COULD: non latin (Russian, Japanese, etc.) (clarify! what's needed for this?)

@What's needed.Sufficient number of buttons on each row to prevent non-punctuation characters from moving away from their default positions (hard to realize due to size constaints).

MUST: is usable using non-sticky modifiers in both of the handheld/desktop modes of typing. (clarify!)

If an Fn value is on the same side of the keyboard as the Fn Key then it is hard to press without utilizing sticky-key behaviour. I.e. your other hand has to cross all-over the keyboard which is uncomfortable. With sticky keys your same hand can press it in sequence, but that is a slower way of input (which I don't like).
Basically a matter of making two-hand key combinations (Fn, shift, Compose,etc...) more comfortable to press. Dual-shift layouts is another example of this.

 

[levi]

Hmm, nesting's still not quite there.


Thanks for those clarifications, Caine.