Keyboard Layout And Durability


Gilrad said:
I'm surprised nobody has mentioned this--or if somebody did, it went ignored because I haven't seen much discussion of it--but what is the deal with everybody mapping various keys to the control pad, face buttons, and shoulder buttons? Looks to me like a formula for some severe inconsistency problems for game and app developers.

MWeston has pointed out the entire keyboard (except Menu) will be software managed anyway.
I think what we're really suggesting is that, by convention, applications that need full keyboard support treat <BUTTON_LTRIG> as Ctrl and <BUTTON_X> as PgDn, whereas a game might treat <BUTTON_X> as "Fire" (and ignore the keyboard entirely).
 
Last edited by a moderator:
I think it would be nice to have an FN key in left and right for right-handed as for left-handed.
Today all examples have a FN key on the right, what is most appropriate for left-handed to enter text.
 
JyCet said:
I think it would be nice to have an FN key in left and right for right-handed as for left-handed.
Today all examples have a FN key on the right, what is most appropriate for left-handed to enter text.
There are barely enough keys for all the functions we need. We certainly don't have enough to go doubling up on keys.

Besides, all thumb-typable devices use sticky keys. It won't be an issue.
 
Last edited by a moderator:
Final revision.
Includes wireless toggle and equalized Fn symbol scaling.
I haven't labelled the "silent" buttons (ctrl, accent etc) because, frankly, it's now irrelevant to the actual printing and can be finalized later.

4h5h80.png


EDIT:
Unlabeled functions: Tab, Ctrl, Alt, PgUp/Down, Home/End, Accent, SysRq
These are mapped to the game controls. Suggested mappings are earlier in the thread, but could be revised without affecting the printing.

SVG source
 
Kagato said:
Gilrad said:
I'm surprised nobody has mentioned this--or if somebody did, it went ignored because I haven't seen much discussion of it--but what is the deal with everybody mapping various keys to the control pad, face buttons, and shoulder buttons? Looks to me like a formula for some severe inconsistency problems for game and app developers.

MWeston has pointed out the entire keyboard (except Menu) will be software managed anyway.
I think what we're really suggesting is that, by convention, applications that need full keyboard support treat <BUTTON_LTRIG> as Ctrl and <BUTTON_X> as PgDn, whereas a game might treat <BUTTON_X> as "Fire" (and ignore the keyboard entirely).


But what about games that want to use the keyboard? It would mean that in order to be able to use the pgdown function (useful for chat logs, for instance), the dev would have to rearrange the keyboard. Similarly, in a keyboard-centric app, there might be a more relevant way to map the dpad and buttons, but if the dev wants full keyboard support, he will end up having to hack away at the default setup. The end result are two different control configurations that not only differ with the face buttons, but in the structure of the keyboard as well.
 
Last edited by a moderator:
Gilrad said:
Kagato said:
Gilrad said:
I'm surprised nobody has mentioned this--or if somebody did, it went ignored because I haven't seen much discussion of it--but what is the deal with everybody mapping various keys to the control pad, face buttons, and shoulder buttons? Looks to me like a formula for some severe inconsistency problems for game and app developers.

MWeston has pointed out the entire keyboard (except Menu) will be software managed anyway.
I think what we're really suggesting is that, by convention, applications that need full keyboard support treat <BUTTON_LTRIG> as Ctrl and <BUTTON_X> as PgDn, whereas a game might treat <BUTTON_X> as "Fire" (and ignore the keyboard entirely).


But what about games that want to use the keyboard? It would mean that in order to be able to use the pgdown function (useful for chat logs, for instance), the dev would have to rearrange the keyboard. Similarly, in a keyboard-centric app, there might be a more relevant way to map the dpad and buttons, but if the dev wants full keyboard support, he will end up having to hack away at the default setup. The end result are two different control configurations that not only differ with the face buttons, but in the structure of the keyboard as well.


Any game that doesn't use the game controls and keyboard at the same time would just go into Keyboard mode and use one of the middle 3 buttons to end keyboard mode. Also, even if it did need both the game controls and the keyboard at the same time, if it has you reading something that needs scroll, then it will probably map either the Dpad, or one of the 2 nubs to scroll.

-God Ginrai
 
Last edited by a moderator:
Kagato said:
Final revision.
Includes wireless toggle and equalized Fn symbol scaling.
I haven't labelled the "silent" buttons (ctrl, accent etc) because, frankly, it's now irrelevant to the actual printing and can be finalized later.

Maybe you could label the silent keys with the arrow leaders, and the actual label would be written completely outside the keyboard? This way we would know what the key means, and we would understand that it is not printed on the key.

I have googled a picture of what I mean by arrow leader.
 
Last edited by a moderator:
cosurgi said:
Maybe you could label the silent keys with the arrow leaders

I could, and I did consider it; but as I said above, it's really not relevant to the current priority to define the button labeling. I've updated my post to include a list of the hidden keys. As long as we can agree that those keys are all suitable for "unlabeled" status and can map to the game controls, the labels can be nailed down for production, and the remainder can be decided before release.

For example: another mapping is Fn-Up/Down as PgUp/PgDn; Fn-(Y)/(X) as Home/End; L as Ctrl, and Fn-L is Accent. This would leave the base game buttons free for OK/Cancel duty in applications. It might be better, but it doesn't affect the labeling I've suggested.

I don't want the printing decision to get unnecessarily bogged down on the secondary keys.
 
Last edited by a moderator:
I like Kagato's design, and I think that it is most likely to win the poll. However I wanted to give people a reasonable choice to vote for Ctrl, Alt on bottom left. And so I did only this:
1. put Ctrl Alt on bottom left
2. therefore the mouse switch is no longer necessary, so put a wireless switch there
3. put remaining IMO least used 6 characters as a Shift+Fn on the other keys (because 6 characters were in place of Ctrl and Alt).
4. Everything else is the same very similar. (I've put Accent on Ctrl, AltGr on Alt, TAB on Space)

like_kagato_with_ctrl_alt.png

SVG source
 
Interesting idea, cosurgi. It keeps the symbol layout closer to a traditional keyboard. (Doesn't leave much room for AltGr labels should they become possible later on though.)
It means you can't hold-fn-and-press for the six second-fn symbols, but they're infrequent characters except + & -.

You'll have to relabel Fn, because shift-Fn isn't Fn Lock any more. (fn2?)
Actually, I'd probably suggest Fn-Fn (press twice), that way it's just *tap*tap*-A for ~.

My personal preference is for ctrl & alt on the shoulders, because you can hold-and-press any key same as usual, but I can understand people wanting a labeled key instead.
 
An update from my previous design.

Keyboard

Cosurgi, the Fn+shift approach is very interesting. However, in my opinion, this would be easier if Fn and shift were next to eachother such that you can hit both with a single thumb and use the other hand to strike the required key (although, it might also increase the amount of misspresses).

-Caine.
 
Caine said:
An update from my previous design.

Keyboard

Cosurgi, the Fn+shift approach is very interesting. However, in my opinion, this would be easier if Fn and shift were next to eachother such that you can hit both with a single thumb and use the other hand to strike the required key (although, it might also increase the amount of misspresses).

-Caine.


Very nice, I like that one.
 
Last edited by a moderator:
Caine: I'm not sure about using an analog stick direction as a button press...
But my main question is, why assign a mapping for Num Lock? You don't have a numeric keypad :)
 
Kagato said:
Caine: I'm not sure about using an analog stick direction as a button press...
But my main question is, why assign a mapping for Num Lock? You don't have a numeric keypad :)
and tested on my laptop the numeric keypad simulated is not easy to use : i only use with tuxmath because not really ergonomic and tuxmath use scancode instead of characters :huh: : hate this
 
Last edited by a moderator:
QUOTE
Caine: I'm not sure about using an analog stick direction as a button press...

Neither am I. I would have to try it out first. In my initial design I also wrote that you could hold the stick to modify the action of the stylus. I expect that the touchscreen would simulate a mouse much nicer than the analog stick can. This reminds me that we also need a modifier direction for just moving the mouse (e.g. to hover above a control with the stylus). ScummVM on the DS does this with the dpad if I recall correctly.

Using this modifier behaviour would require the ability to swap to functions of the two analog sticks for left handed people, which can be done at a software level.

If time permits it, I will try this with my gamepad tonight to see how it feels.

QUOTE
But my main question is, why assign a mapping for Num Lock? You don't have a numeric keypad

Mainly for the sake of completeness. This way all regular keyboard keys are available. However, num lock has no label on the unit and its function is software controlled anyway.

In might be useful in case any application hooks into the num lock state (which I admit is not very frequent).
I have also been thinking about overlaying a numeric keypad on the right half of the keyboard, but it becomes rather crowded and messy.

I suppose the same thing holds to a lesser extent for the scroll lock, pause, Print Screen/SysRq, the AppKey and the Winkey. They are not as essential.
 
Scroll on the analog stick might not be bad. You could have maybe 0-33% on the Y-axis be equal to 1 line scroll. 33-66% 6 line scroll. 66-99% 10 line scroll. And at +100% Y axis home or end at -100% Y axis.

For X-axis you could do the same idea. 0-33% 1 char at a time. 33-66% one word at a time. 66-99% one sentence at a time. 100% one line at a time.

percentages and movement intervals are just for an example :)
 
Karel Jansens said:
Just a heads up: The keyboard layout seems to lack the "accent aigu". At least, I can only find the "accent grave" (on the "A").
I was planning ` (Fn+A) for grave accent, and ' (Fn+L) for aigu accent. Is it ok now? :)

Karel Jansens said:
I know that USAnians usually take these accent matters rather loosely, but I know for a fact that they do matter in other languages...

My native language is polish, in EU :p
 
Last edited by a moderator:
cosurgi said:
That's a yet another variation:

1. All labels that I consider unnecessary are removed.
2. Mark Ctrl & Alt because I'll never remember which one is on the left and which on the right. (but I guess that I'll need to put a sticker there, becuase it requires printing on the case)
3. Move all other labels onto the buttons. They become really small, uh.
4. Who needs "Space" on space?
5. Didn't rearrange any symbols - they are the same is in Kagato's final proposal.

pandora_keyborad_another.png


SVG source




This layout would be very nice and most useful.

But isn't the simplistic layout already set in stone?
 
Last edited by a moderator:
Back
Top