Keyboard Layout And Durability

[kagato]

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).

 

[JyCet]

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.

 

[Chip]

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.

 

[kagato]

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.

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

 

[Gilrad]

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.

 

[God Ginrai]

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

 

[cosurgi]

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.

 

[kagato]

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.

 

[cosurgi]

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)

SVG source

 

[kagato]

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.

 

[Caine]

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.

 

[_VWV_]

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.

 

[kagato]

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

 

[Arialia]

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

 

[Caine]

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.

 

[greendots]

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

 

[parag0n]

Can we have a bluetooth toggle as well as the wifi toggle?

 

[Karel Jansens]

SVG source


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 know that USAnians usually take these accent matters rather loosely, but I know for a fact that they do matter in other languages...

 

[cosurgi]

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?

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

 

[IceBerg303]

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.

SVG source




This layout would be very nice and most useful.

But isn't the simplistic layout already set in stone?