Bugzilla – Bug 11512
Support textinput "touch to place cursor"?
Last modified: 2009-09-08 09:12:53 UTC
Relates to bug 11398. From that discussion: Comment #3 From Blackketter Dean 2009-03-25 16:38:06 (-) [reply] ------- The back button on the screen should always take you back a screen. The left arrow on the remote should act as a cursor key until it goes back to the left most position, then back out of the screen. We either need touch-to-move-cursor for MP firmware or put back in the < and > keys for cursor movement. Touch to move cursor would be more ideal. ------- Comment #4 From Wadzinski Tom 2009-03-25 18:37:41 (-) [reply] ------- > > We either need touch-to-move-cursor for MP firmware or put back in the < and > > keys for cursor movement. Touch to move cursor would be more ideal. I just looked at doing a POC implementation for "touch to move cursor" and noticed that we support typing characters longer than the screen width. So if there is space on the screen for 20 characters and the user has a 23 character email address, then only part of it will show on the screen. In that case, a basic "touch to move cursor" wouldn't be enough to get to the "off stage" characters. We would need some sort of logic for shifting what is on stage when you put the cursor near the border of where there is off stage content. As I mentioned I was working on a quick POC, ignoring the off stage and assuming monospaced text, to test out whether there is enough space between letters to have "touch to move cursor" even work on a small touch interface with small fonts (iphone doesn't support it for instance - they do "backspace only" or sometimes just cursor begin or end selection, but maybe they had other reasons) So I held up on the POC to get further feedback given the "off screen" challenge that we would also have to overcome.
One idea for scrolling would be to have a touch at either end start the scroll. that way somebody could "drag" the cursor to the edge of the text, causing the text to move into view, then move back towards the center to find the right place. Should be simple and not need any graphics support. This is how selecting text on desktops and various touch devices work now.
*** Bug 11460 has been marked as a duplicate of this bug. ***
Touch to move or place the cursor is, IMO, highly unintuitive when you're using a *KEYBOARD*. Restore the arrow keys to move the cursor. And make it simpler for the user by eliminating the overstrike mode. It's unnecessary in a text entry box where the longest string being entered is 64 characters. With r5000 it can be nearly impossible to fix an incorrect password and you're sometimes forced to completely wipe the entry box blank to fix a simple typo. If you forget a character, how do you insert it, since re-enter password comes up in an overstrike mode with no way to switch to insert mode? Using 'Done' to move the cursor right (again, extremely unintuitive) also has the effect of placing you in overstrike mode. But then the Backspace key behaves like a PC keyboard's Delete key and starts deleting the character _under_ the cursor. Backspace on a PC never does this - even in overstrike mode it always deletes the character to the _left_ of the cursor. BTW, I have a 45 character WPA passphrase, and it's wider than the text entry box.
I think we should consider adding back the < and > keys for cursor movement, if we can't get the touch-to-place cursor. Tom/Ben: Thoughts?
Tom and I discussed this bug this morning. We both agreed that Touch-To-Place is not a reasonable MP goal at this stage. Also, left/right arrows are consistent with IR remote behavior and fairly intuitive and easy to discover. Recommendation is to add back < > arrows on to all applicable keyboards. Noah, will need your vision on this, but these are the options we've come up with: 1. < > arrows to the left of the "done" key on all keyboards (perhaps not ideal on qwerty keyboards) 2. < > arrows above the "done" key on all keyboards (challenging on IP keyboard) 3. < > arrows to the left of the delete key in the textinput bar (maybe a good option, but the delete key is already kind of ugly, codewise; this would make it uglier)
Created attachment 4999 [details] screenshot of 4 keyboards as currently laid out email keyboard is also an issue for adding arrow keys back in. If arrow keys are to be put to the left of the done key, recommend dropping the .com button in favor of the arrow keys.
assigning to Noah for comment and direction
Thank you for the posts Ben. We have designed ourselves into a bit of a corner:) Let me look at this in more detail and develop a proposal ASAP.
Could we introduce scaling the text after 20 characters?
Above the Done key seems obvious to me, but... The only keyboard where it looks like an issue is the email keyboard. The '.com' is pretty unnecessary, IMO, so wouldn't be hard to work around. The numeric keyboard could have one less special character on the third row. In bug 11547 Dean has suggested adding a shift key to this keyboard to access another keyboard with the missing ASCII characters. So you'd need to move one character from this keyboard to that one, so that the new keyboard has 15 characters instead of 14. The IP address entry keyboard would get a third row to keep the location of the arrow keys in the same position, for consistency. Avoid using the glyphs < and > for the arrow keys if they'll look like the ASCII characters < and > (decimal 60 and 62). Something with a tail would be better: <- and ->.
Re: scaling the text ... might work for short to mid-length passwords, but what will it look like with 63 characters? (the max.)
Looking at the email keyboard again, you wouldn't have to eliminate the .com key. The . and @ keys could easily be made normal sized keys, giving room for the _ and - on the bottom row. Would actually be a better design, IMO, by placing all the punctuation characters in one row.
Created attachment 5008 [details] Ref artwork - proposed arrow placement In the case of HEX entry the arrows would be in the same position as seen in IP reference. The A-F would be moved left with the A aligned below the 1. In the case of EMAIL entry to access remaining characters the user would toggle into 123-&. This is a trade-off, however, it maps out better on a whole.
Created attachment 5009 [details] Ref artwork - Keyboard HEX arrows
Assigning to Dean for decision.
(In reply to comment #13) > In the case of EMAIL entry to access remaining characters the user would toggle > into 123-&. This is a trade-off, however, it maps out better on a whole. Big thumbs down on the proposed email keyboard. IMO, dot (.) and underscore (_) must be on the top level of this keyboard. There is only a certain subset of valid ASCII characters that may appear within the local part of an email address. So you don't want to use the general special character keyboard(s). A 2nd keyboard with digits 0-9, and the characters cited below is what is needed. I've personally never seen an email address containing the special characters mentioned, other than dot, underscore and hyphen. http://en.wikipedia.org/wiki/E-mail_address > The local-part of the e-mail address may use any of these ASCII characters: > > * Uppercase and lowercase English letters (a-z, A-Z) > * Digits 0 through 9 > * Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~ > * Character . provided that it is not the first nor last character, > nor may it appear two or more times consecutively. > ... > > Notwithstanding the addresses permitted by these standards, some systems > impose more restrictions on e-mail addresses, both in e-mail addresses > created on the system and in e-mail addresses to which messages can be > sent. Hotmail, for example, only allows creation of e-mail addresses > using alphanumerics, dot (.), underscore (_) and hyphen (-), and will > not allow sending mail to any e-mail address containing ! # $ % * / ? > | ^ { } ` ~
r5132 has left/right arrows in all the keyboards. .com button, which was cool but the least useful thing on the screen, was removed in email keyboards to make room for these. the right arrow event handling still needs tweaking because it issues KEY_GO which works for going right within the textinput, but at the end of the input string KEY_GO acts as a submit. Not sure we want that... similarly, left arrow issues a KEY_BACK which works until the beginning of the string is hit, then KEY_BACK exits window. Again, not sure we want that. Leaving the bug open, the UI for adding the arrows to all the keyboards (including localized FR/DE/PL keyboards) is now complete.
fully fixed, r5140