Are there any standards on keyboard manipulation?
I've thought about the problem of typing with the limited amount of buttons on the GP2X. One solution is a field with all the buttons and scrolling toward the correct one... it sucks.
I think that the lowest average amount of required buttons pushed per symbol is a 2.something, for instance this text, i only use mainly the letters the space and upper/lower-case. if i start with numbers, i may be doing that for a while too.
Now my suggestion:
To keep things simple each symbol is reachable though a selector and then a tree. Moving trough text is done with the stick.
the selector reads: letter, numbers, action,
parsing through the selector is done with L-button. the a,b,x,y,R-buttons initiate a symbol selection.
When this symbol selection is initiated what happens is dependend on what the selector reads. the select button becomes back one.
in case of letter buttons lead to menus with the letters (alphabetical seems logical, also easier display):
Y: abcdef
B: ghijklm
X: nopqrs
A: tuvw<space><newline>
R: <tab><,><.><capital><backspace><something>
with capital leading to uppercase letters tree (same thing as here)
with the letters below the buttons numbers selected with Y,B,X,A,R,L-buttons (L changes function)
same thing with selector at numbers, just:
Y: 123456
B: 7890-+
X: *(){}<more1>
A: []:;/\
R: <>:;<more2><more3>
more1,2,3 could lead to yet other symbols
Action could lead to copy/paste delete options and such.
I've thought of a system which uses only the selector, having each button scrolling in different directions, but it costs much more button-pushes that way. I am pretty sure the tree after selector method is close to optimal. (the actual position of symbols above could be better though.. also maybe a few positions could be user-defined)
I'd like some responses from people dealing with typing emulation, i am thinking of making a text editor for the GP2X and it would be usefull if people accustomed to this system would not have to relearn for each application.
I've thought about the problem of typing with the limited amount of buttons on the GP2X. One solution is a field with all the buttons and scrolling toward the correct one... it sucks.
I think that the lowest average amount of required buttons pushed per symbol is a 2.something, for instance this text, i only use mainly the letters the space and upper/lower-case. if i start with numbers, i may be doing that for a while too.
Now my suggestion:
To keep things simple each symbol is reachable though a selector and then a tree. Moving trough text is done with the stick.
the selector reads: letter, numbers, action,
parsing through the selector is done with L-button. the a,b,x,y,R-buttons initiate a symbol selection.
When this symbol selection is initiated what happens is dependend on what the selector reads. the select button becomes back one.
in case of letter buttons lead to menus with the letters (alphabetical seems logical, also easier display):
Y: abcdef
B: ghijklm
X: nopqrs
A: tuvw<space><newline>
R: <tab><,><.><capital><backspace><something>
with capital leading to uppercase letters tree (same thing as here)
with the letters below the buttons numbers selected with Y,B,X,A,R,L-buttons (L changes function)
same thing with selector at numbers, just:
Y: 123456
B: 7890-+
X: *(){}<more1>
A: []:;/\
R: <>:;<more2><more3>
more1,2,3 could lead to yet other symbols
Action could lead to copy/paste delete options and such.
I've thought of a system which uses only the selector, having each button scrolling in different directions, but it costs much more button-pushes that way. I am pretty sure the tree after selector method is close to optimal. (the actual position of symbols above could be better though.. also maybe a few positions could be user-defined)
I'd like some responses from people dealing with typing emulation, i am thinking of making a text editor for the GP2X and it would be usefull if people accustomed to this system would not have to relearn for each application.