The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Text editing using only arrow keys

I am developing some portable device, where a user needs to enter text using only 4 arrow keys. Is there any standard way how to do it in the UI? I was thinking about:

1) Simple rotating 0-9 and then A-Z when Up key is pressed

2) Display a pallete of all ASCII characters, so the user can quickly select the character he wants using all arrows.

Any other ideas? To be honest, I don't know where to search about this...

Thanks,
Petr
Petr Veit
Friday, January 04, 2008
 
 
I guess option 1 is the worst case you can ask user to do, really. Option 2 would work, but you would spend really much time on how to show the letters the way it's comfortable to use.
Roman Send private email
Friday, January 04, 2008
 
 
Presumably 4 arrow keys and an "enter" key?

Two precedents come to mind:

Mobile phone texting. Use arrow keys to move between 10 multifunction areas, enter to cycle through functions (a or b, or c ...).

If data entered is in some way limited by a "dictionary" then you can use preductive texting.

Also consider SatNav systems. Some exploit the "dictionary". they show a "keyboard" navigated by arrow keys. But the speed up navigation by only showing the valid next characters. The further you get into a word the fewer letters are valid options.
Dave Artus Send private email
Friday, January 04, 2008
 
 
Thank you for your replies guys.

Yes, I have available 4 arrow keys, Enter and Esc. Users will enter random texts including shorts, so the dictionary is not usable here.

Truth is that entering text will be probably very annoying. I've tried the board of all characters and well, it doesn;t seem very comfortable to me. Would you recommend standard PC keyboard layout or just 0-1-A-Z order?

Another problem is that during selecting the letters, the Enter key adds the selected letter to the edited text, Esc key should leave the menu immediately. Now I have no key for finishing the text (usualy users will not fill the whole text).

I tried to look on digital cameras, where they have also only arrow keys, but they don't need to edit texts.
Petr Veit
Friday, January 04, 2008
 
 
Try and have a look at something like non-touch-screen satnavs. Something like this:
http://www.pocket-lint.co.uk/reviews/review.phtml/1249/2273/garmin-i3-gps-satellite-navigation.phtml

It has a single up-down scrollwheel (that is also clickable) for entering addresses and post/zip codes. I think it works very well and is actually suprisingly fast.
Adrian
Friday, January 04, 2008
 
 
The single key system used by disabled users (eg Stephen Hawking) is called "eLocutor".
Even if you don't use this, it does require a lot of screne space, they have a series of articles describing their design choices.
Martin Send private email
Friday, January 04, 2008
 
 
I recall seeing both used to enter your score on video games back in the day.  Some would have you cycle through a series of letters; the other would have you use the joystick to move around a grid of letters, and it'd show your choices at the top.  I found the latter far easier to use.  So personally, I'd pick option 2.
Kyralessa Send private email
Friday, January 04, 2008
 
 
I agree with the others that suggest having some kind of on-screen keyboard. For more efficiency, look into alternate layouts like FITALY. Yeah, some people think they won't like to change layouts, but I've never yet had anybody go back to a single layout for every input method once I got them convinced to try something designed specifically for the input method.
Ron Porter Send private email
Friday, January 04, 2008
 
 
From the standpoint of minimizing keypresses, it’s probably better to _zoom in_ on a character in a palette, not to cursor to a character and hit Enter. Present your characters in alphabetical/numeric order in fours groups of top, bottom, left, and right. The first keypress of a cursor key selects a group, the second keypress selects a character in the group or a subgroup in the group, and the third keypress selects a character from the subgroup if necessary.

The Enter key is _not_ used to finalize the selection. Instead when the selection is narrowed down to one character, it’s automatically entered. If the user makes an error, s/he must press Esc and start over, a minor cost, given it’s only 1 to 3 keypresses to redo, in order to avoid an extra keypress (Enter) with every correct entry.

For example, if the characters are A-Z (no lower case, no spaces) and 0-9 (no decimals or negative sign), one group (say, the Up cursor key) is 0-9, with subgroups for 1-4 (Left cursor) and 5-8 (Right cursor). 0 and 9 are selected with Up and Down cursors respectively. Thus, entering "92" would be something like Up-Down (for "9"), Up-Left-Up (for "2," assuming "2" is the Up key in the 1-4 subgroup). It’s similar for letters: 2 of the remaining cursors keys access 2 subgroups and 2 letters directly, and the 1 remaining cursor key accesses 1 subgroup and 3 letters directly. That makes (4 + 4 + 1 + 1) + (4 + 4 + 1 + 1) + (4 + 1 +1 + 1) = 27 letters accessed by three keys in 2 or 3 keypresses (and maybe you can have a space character after all).

If the entry is truly random alphanumeric strings with equal frequencies of each character, the average kepresses per character is about 2.7. In contrast, cursoring and hitting Enter in a palette takes something like 4.5 keypresses per character –67% slower (I’m figuring a 6x6 palette).

To get the best performance, you select your groups and subgroups so that the most frequent characters tend to be selected with 2 rather than 3 keypresses. For example, with English words being entered, you want groups and subgroups like (A, (B,C,F,G), D, E), ((H,I,J,K), (L,M,P,Q) N, O), (R, (S,U,V,W) T, (X,Y,Z)). This will shave the average keypresses per letter down to about 2.5 to 2.4.
Michael Zuschlag Send private email
Friday, January 04, 2008
 
 
Another good example is Dasher http://www.inference.phy.cam.ac.uk/dasher/
Martin Send private email
Friday, January 04, 2008
 
 
You might, if your device has the horsepower to manage it, include an autocomplete feature.

Some phones have that for text messaging.

This is assuming that you will be entering text as words, of course.
frustrated
Friday, January 04, 2008
 
 
How often will one person use the device to enter text? Every day, once a month, once a year?
If text entering is done once a year, choose a simple method. If it's supposed to be used every day, maybe some research and user testing should be done. In the best of worlds, there should be two ways to enter text: One simple way with no learning curve and one more advanced that maybe would require some practising.

Monday, January 07, 2008
 
 
It seems that text editing will not be used very often, say once a month or so. I will try to do it some simple way, probably with the pallete of letters.

Thanks all for responses!
Petr Veit
Monday, January 07, 2008
 
 
If you require the users to learn Morse code, you could have up arrow be the dashes, down arrow be the dots, right arrow to commit, and left arrow to backspace.  :)
Kyralessa Send private email
Thursday, January 10, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz