Pyra keyboard layout - requirement analysis


Caine

Hardcore Member
Joined
Jun 5, 2008
Messages
4,136
Location
Netherlands
There are many good ideas in the keyboard layout thread, but I feel it is getting a bit unfocused since everyone is optimizing towards non agreed requirements.

How about brainstorming a bit about what we actually want from the keyboard layout.

Here is a start. The Pyra keyboard:

  • must support 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.
  • would be nice if it had support for alternative keycodes for left/right hand modifiers and regular and keypad keys.
  • must support the following gaming controls: dpad, left nub, right nub, A, B, X, Y, L1, R1.
  • should support the following gaming controls: L2, R2, start, select, menu.
  • should have a Pyra button for a system-global menu.
  • could have 6 gaming control buttons (A,B, X,Y, C,Z)
  • should allow for both handheld thumbtyping and desktop finger typing (e.g. don't rely on shoulder buttons alone for modifiers).
  • should be usable using non-sticky modifiers in at least one of the handheld/desktop modes of typing.
  • must not force the pyra dimensions to exceed handheld-size (refer to the pyra size thread).
  • 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
  • must be easily remappable into azerty and qwertz layouts
  • must be mappable to support the keys of the US international layout
  • should be mappable to acceptable dvorak and colemak layouts
  • could be mappable to non latin characters layouts (e.g. Russian, Japanese, Hebrew, ...)
  • should, by default, not break the correlation between a key and its shifted value (e.g. ; and : ) on the US international layout.Note that this does not apply when this are bound separately as Fn value on different keys.
Getting this list more complete and well defined will help us in evaluating proposals and will ensure that we can design layouts which try to optimize for all our wishes instead of just our personal preferences. Regarding the severity of must/should/could/would be nice, if there is a need then we can have a vote once this list matures.
My ideal end situation would be that we can communicate a (mostly) agreed upon (accents will always differ) list of requirements to ED and a series of layouts and ideas of how to satisfy those requirements. The final decision is naturally his, but I would like to present a well discussed summary of our ideas.

We eventually need to solve the following issues:

  • button placement
  • default key binding
  • labels
These are somewhat separated issues, but derive from our requirements.
Discuss...

Related threads: 6-buttons-abcdxy-and-4-shoulder-buttons and Unofficial-pyra-keyboard-layouts
 
Last edited by a moderator:
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.
 
http://www.keyboard-layout-editor.com/#/layouts/d61aad10e1a89de33e5224f26e9cafb0

This one from _wb_ is pretty good.

Shift buttons as big as the other buttons and the Ins key upwards (same heigh as DEL) and it's great.
Can you quantify a bit what you like about it? Strong points in terms of Pyra size, button placement, grouping of special characters, ease of access of such characters and/or button combinations, etc...
The better we understand this, the easier we can incorporate these into other layouts as well.
 
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?  

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 ? 
 
must be easily remappable into azerty and qwertz layouts
Surely you mean qwerty and not qwertz?

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. 
 
must support the following gaming controls: dpad, left nub, right nub, A, B, X, Y, L1, L2. should support the following gaming controls: R1, R2, start, select, menu.
Probably you meant R1 instead of L2 in the first line. 

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

- must support the following gaming controls: dpad, left nub, right nub, A, B, X, Y, L1, R1, Start, Select just like on the current Pandora. 
 
Why I like _wb_'s layout:

1: All necessary buttons are available.

2: It's pretty close to the Pandora Keyboard.

3: There are 2 more gaming buttons.

4: Only 12 buttons in a row -> realistic dimension.

5: Hardware buttons (Wifi, BT,...) are well used
 
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 ?
In my experience, in requirements analysis, 'should' is stronger than 'could' but weaker than 'must'. And while 'musts' are the only ones strictly required, requirements analysis acts to catch all common preferences too.

I think we should establish how far we want to follow the Pandora layout. So far most people seem to be following it for start and select, but not for the symbols over the numbers in the US layout. Speaking of which, what is the US international layout, for reference? I've only come across the US 101 key layout and various other nations 102 key ones.


I'd like to add some 'should' requirements that common shell characters such as Tab, pipe, hyphen, backtick, quotes, dollar, plain brackets (parentheses) and curly, ampersand and slash should be accessible without chording two keyboard characters. Chording a shoulder button with a keyboard character is acceptable though :)
 
Yeah, 'must, should and could' (along with 'won't') is more agile development than requirements, but as long as you stick to one set or the other nobody gets confused.
 
1. Some sort of feedback when a button is pressed.

2. Easy to count keys with your thumb in the dark so you can find the 'right' key without backlighting.

3. Resistant to foreign matter (pocket lint) from getting into the keys (if mechanical).

4. Backlighting with variable brightness and color.

5. Inexpensive to produce. Pandora's keymat was sub $10. Pyra's should be a similar cost.

6. I'd prefer black/red/blue/green symbols on a translucent white key, but I seem to be a minority on that.

7. No crowding around the game controls or the 'thumb space' leading in to them from the sides.

Is that what you're after?
 
How about dimples to help locate keys by touch.

I often find my self typing too fast to keep track of finger position consciously, and tend to slide my thumb across the keyboard rather that lifting it fully of the keys.
 
1. Some sort of feedback when a button is pressed.

2. Easy to count keys with your thumb in the dark so you can find the 'right' key without backlighting.

3. Resistant to foreign matter (pocket lint) from getting into the keys (if mechanical).

4. Backlighting with variable brightness and color.

5. Inexpensive to produce. Pandora's keymat was sub $10. Pyra's should be a similar cost.

6. I'd prefer black/red/blue/green symbols on a translucent white key, but I seem to be a minority on that.

7. No crowding around the game controls or the 'thumb space' leading in to them from the sides.

Is that what you're after?
Yes, basically, we need more people listing requirements like this to help us come up with a comprehensive set of requirements and recommendations.

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

1000px-Qwerty.svg.png


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
 
Back
Top