Pyra keyboard layout - requirement analysis


width: SHOULD: is as wide if not wider than the Pandora (ED)
This is one point where I disagree with ED.  Shaving ~1mm from the key width would make little difference to usability,  but would allow another column of keys to be added without increasing the width of the device.   Adding another column of keys would make it a lot easier to provide a layout that includes things like ED's desired second shift key,  while still allowing enough keys for all the various symbols and modifiers.

- Neelix
 
Reordered, clarified, commented. Moved some stuff back to 1.1.2 because they didn't belong to 1.1.1.

  • hardware
    keyboard:
    MUST: is possible to find the keys by touch
    surface form: flat? rounded? concave?
  • surface height: (T4b: no higher than on current Pandora)
  • MUST: surface coating: non sticky, fingers must glide over it as easily as possible
  • MUST: allows for both handheld thumbtyping and desktop finger typing
  • MUST: minimum force needed to trigger key: is possible to slide finger over key without triggering it
[*]MUST: individual keys easy to press
  • maximum force needed to trigger key: must not be so big as to make it difficult to press the key (clarified?) (too obvious to include? But I guess we should also include trivial things)
  • maximum way/travel needed to trigger key: (T4b: must be low, say 0.3mm, max 0.5mm)
  • room between keys: (T4b: could be lowered I guess, but only technically possible if the plastic ribs between the keys aren't necessary anymore)
  • size of individual keys:
    SHOULD: width is as wide if not wider than the Pandora (ED)
  • MUST: height: is no taller than the Pandora (ED)

[*]MUST NOT: forces Pyra's dimensions to exceed 1-2mm beyond the Pandora's
[*]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?)
[*]MUST NOT: keyboard gets into the way when gaming
  • <practical considerations>

[*]keyboard and gaming controls:
  • 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
[*]gaming controls:
  • NOTE: I think the individual action buttons 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. (T4b: the keyboard could cost a lot more than $10 if it's also considerably better if you ask me)

[*]software (default key bindings)
  • SHOULD: is similar to Pandora's
  • SHOULD: is similar to US international qwerty
    SHOULD NOT: break the correlation between a key and its shifted value (e.g. ; and : ) on the US international layout.
[*]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)
  • SHOULD: two shift keys on main keyboard (ED)
  • COULD: different keycodes for different versions of the same keys (T4b: "support" should be a given, it's more about the default layout, isn't it? Did I express it better?)
[*]what to map to the gaming controls?
[*]MUST: is usable using non-sticky modifiers in both of the handheld/desktop modes of typing. (clarify!) (T4b: I guess this is similar to 2.3.2, the most important characters shouldn't need sticky modifiers to input)
[*]MUST NOT: prevents valid regular keyboard combinations from being input (e.g. shift-backspace on the Pandora) (T4b: What's that about again?)
[*]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
[*]COULD: W-LAN, Bluetooth, etc.
 
I wonder, could 1.1.1 be downgraded to a SHOULD if we get backlighting?


Also, it occurs to me that 1.1.1 isn't really a subject heading, since even if it were to be downgraded to a SHOULD, its contents would still be MUSTs. Section 1.1.5 (backlighting) on the other hand is a SHOULD with a MUST in it, and that MUST doesn't count if the SHOULD doesn't get implemented. That's not the case with 1.1.1.
 
I just noted 1.1.1.4 actually doesn't belong to 1.1.1, I moved it to it's own point.

  • hardwarekeyboard:MUST: allows for both handheld thumb typing and desktop finger typing
  • MUST: is possible to find the keys by touch (for thumb typing)surface form: flat? rounded? concave? (T4b: I would like them to be more or less flat and concave a little bit so you feel the different keys better)
  • surface height: (T4b: no higher than on current Pandora, preferably almost (only almost!) flush with the rest of the surface)
  • MUST: surface coating: non sticky, fingers must glide over it as easily as possible
  • MUST: minimum force needed to trigger key: is possible to slide finger over key without triggering it
[*]MUST: individual keys easy to press
  • maximum force needed to trigger key: must not be so big as to make it difficult to press the key (clarified?) (too obvious to include? But I guess we should also include trivial things)
  • maximum way/travel needed to trigger key: (T4b: must be low, say 0.3mm, max 0.5mm)
  • room between keys: (T4b: I would like to get rid of it completely, but only technically possible if the plastic ribs between the keys aren't necessary anymore)
  • size of individual keys:SHOULD: width is as wide if not wider than the Pandora (ED)
  • MUST: height: is no taller than the Pandora (ED)
[*]MUST NOT: forces Pyra's dimensions to exceed 1-2mm beyond the Pandora's
[*]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?)
[*]MUST NOT: keyboard gets into the way when gaming
  • <practical considerations>
[*]keyboard and gaming controls:
  • 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
[*]gaming controls:
  • NOTE: I think the individual action buttons 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. (T4b: the keyboard could cost a lot more than CHF9.27 ($10) if it's also considerably better if you ask me)
[*]software (default key bindings)
  • SHOULD: is similar to Pandora's
  • SHOULD: is similar to US international qwertySHOULD NOT: break the correlation between a key and its shifted value (e.g. ; and : ) on the US international layout.
[*]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)
  • SHOULD: two shift keys on main keyboard (ED)
  • COULD: different keycodes for different versions of the same keys (T4b: "support" should be a given, it's more about the default layout, isn't it? Did I express it better?)
[*]what to map to the gaming controls?
[*]MUST: is usable using non-sticky modifiers in both of the handheld/desktop modes of typing. (clarify!) (T4b: I guess this is similar to 2.3.2, the most important characters shouldn't need sticky modifiers to input)
[*]MUST NOT: prevents valid regular keyboard combinations from being input (e.g. shift-backspace on the Pandora) (T4b: What's that about again?)
[*]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
[*]COULD: W-LAN, Bluetooth, etc.
Edit:

Also, it occurs to me that 1.1.1 isn't really a subject heading, since even if it were to be downgraded to a SHOULD, its contents would still be MUSTs. Section 1.1.5 (backlighting) on the other hand is a SHOULD with a MUST in it, and that MUST doesn't count if the SHOULD doesn't get implemented. That's not the case with 1.1.1.
It's supposed to be so that MUSTs inside SHOULDs are only MUSTs if the SHOULD is implemented. Same with 1.1.1, I think it's sub points are only MUSTs if 1.1.1 is a MUST (which it of course is).
 
Last edited by a moderator:
I would add 1.2.5 SHOULD: raised markers on the F and J keys.

While the keyboard is too small to be used for touch typing it still makes sense to make these keys easily locatable by touch as a point of reference.

- Neelix
 
I think you mean 1.1.2.5. Good idea, I think. I don't know about "raised markers", but some way to tell them apart by touch: yes.

Fuck bb-code. I'm migrating this list to the wiki.

Edit: Done and suggestion by Neelix integrated. Though Wiki Syntax is hardly any better. At least we get diffs, history and so on.

http://pandorawiki.org/Keyboard/Requirement_Analysis_Pyra
 
Last edited by a moderator:
To respond to your comment on 2.5: It might been similar features, but the use cases are different. 2.3.2 is concerned with shell scripting while handheld, and defines what usable means, wheras this is concerned about finger typing as well as thumb typing. My concern in writing 2.3.2 was that moving both hands while supporting the device is a little tricky, but if you've got the device on a table for finger typing then that's not a concern and it's more about key response and size so it's easy to hit the modifier with a weaker finger of either hand, I guess.


And to be 2.6 is about what it says it's about: on Pandora it's not possible to hit shift-backspace and get the Delete key (i.e. in-place delete), despite the keymap being labelled as such. The point of that requirement as I read it is to avoid that sort of thing happening again. We could do with someone who understands why it's not possible to assign to shift-backspace to explain it to us, and list any other keys we ought to watch out for.


Note I seem to be able to get the Insert key at Fn-backspace (though I didn't test it fully as I don't have a use for that key), so it seems Fn-backspace works, just not shift-backspace.
 
Last edited by a moderator:
Regarding your edits: Shell usage keys are almost the same as coding, so we should maybe group them together. We would just need to add [] (which you removed) and then that would probably be most coding relevant characters.

That fucking currency mix is caused by a plugin I have which always inserts prices in CHF. It's nice in general, but in this case it's annoying. Just remove the CHF, that is completely irrelevant.

2.6: Maybe change that to "Labels should reflect the default keymap." and move it to hardware? Because that's what it is, isn't it?

I think the software part needs more structuring and thinking in general (more than the hardware part), but too lazy right now.
 
Fuck bb-code. I'm migrating this list to the wiki.
Good idea. 
And to be 2.6 is about what it says it's about: on Pandora it's not possible to hit shift-backspace and get the Delete key (i.e. in-place delete), despite the keymap being labelled as such. The point of that requirement as I read it is to avoid that sort of thing happening again. We could do with someone who understands why it's not possible to assign to shift-backspace to explain it to us, and list any other keys we ought to watch out for.
On a regular keyboard shift-backspace is a valid key combination, so is shift-delete (commonly used for permanent deletion). By mapping del onto shift-backspace, you make both combinations unreachable as shift+backspace is a del and shift + del would be shift + (shift + backspace) which is just shift + backspace and thus del.
Some safety rules:

  • Never put a non-shifted key (normal keyboard) on a shifted position.
  • Maintain correlation between normal value and shifted value (2.2)
  • Don't put a shifted value on a button which normally has none (space, enter, backspace, tab, capslock, shift, ctrl, alt, insert, delete, home, end, pageup, pagedn, F1-F12, ESC, Print Screen, Scroll lock, Pause, NumLock, direction keys and numeric keypad / * - + enter).
  • Don't put additional keys on common modifiers (Ctrl, Alt, Shift, Hyper, Meta, Compose)
  • Putting a value on Fn+<some key> is generally safe (unless <some key> is a modifier).
 
Hmm, on this netbook with separate del and bs keys, shift-bs is just bs and shift-del is a new code my terminal doesn't have a glyph for.
So? The fact that your test application doesn't bind anything to shift+backspace doesn't mean it can't be bound.
As mentioned, file managers often use shift+del to skip deleting to trash.

<edit>It is not just about generating glyphs, application keyboard shortcuts are important to consider.</edit>
 
Last edited by a moderator:
Sorry, I thought you were saying shift-delete was backspace on all keyboards. That might explain why shift-backspace just gives me a backspace in the terminal on my Pandora, but as is I still don't understand why that happens.


It does however explain that shift-delete is an important and inaccessible key on the Pandora keyboard. If that was your point (rather than the fact you can't access delete at all) then fair enough. Sorry, I'm having a bit of difficult understanding that paragraph you wrote.
 
Sorry, I'm having a bit of difficult understanding that paragraph you wrote.
Heh, you are right. I haven't phrased it very clearly.
Bottom line is to safeguard the possibility of inputting key combinations which are valid on full sized keyboards.
 
Okay, I've moved that point to 2.3.3 and had a go at rewriting it. Hopefully it's clearer now, and I haven't lost the point of it.


http://pandorawiki.org/Keyboard/Requirement_Analysis_Pyra


I see what T4b was talking about regarding point 2.5 (keyboard usable for touch typing) being similar to point 2.3.4 (keyboard suitable for shell coding when thumb typing) since they both talk about keyboard modifiers, but I suspect it's actually more like ED's point 2.3.6 (two shift keys) since they both are specific to touch typing IMO. Point 2.3's growing quite a lot now - I wonder if we should split it down the lines of touch typing requirements and thumb typing requirements?
 
Back
Top